home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.amiga.misc
- Path: EU.net!sun4nl!hguijt
- From: hguijt@inter.NL.net (Hans Guijt)
- Subject: Re: OS features
- Message-ID: <DLE6q5.71B@inter.NL.net>
- Organization: NLnet
- X-Newsreader: TIN [version 1.2 PL2]
- Date: Thu, 18 Jan 1996 19:42:05 GMT
-
-
- (sorry for a chaotic posting - I added to it on 4 occasions and this didn't
- help textflow)
-
- Michael van Elst (mlelstv@serpens.rhein.de) wrote:
- >>What other functions do you mean here? Keep in mind that not everybody is
- >in
- >>the business of writing 'normal' programs. Some people need more, and so
- >far
- >>I think the Amiga catered well to them.
- >
- >Oh.. Things like SuperState() or SetIntVector().
-
- I agree, to a point. The real functionality of SetIntVector () is not 'put
- the machine into supervisor mode', rather it is 'react quickly to some
- hardware event you think you can handle better then the OS'. This
- functionality is necessary for some hardware drivers (anything that uses
- int7 for instance).
-
- And I don't see a use for SuperState, but that just means I cannot foresee
- all possible future uses for the Amiga.
-
- Does PPC have user/supervisor modes anyway?
-
- The point I wanted to make was that neither you nor I can foresee where the
- Amiga will be used, nor should we try to limit it to our vision. If the NASA
- wants to use the Amiga in a future spaceship but can only do so if the Amiga
- can process interrupts in a certain way I don't want them to turn to clones
- because DOS allows the ultimate flexibility of not having an OS to worry
- about.
-
- >And don't get me wrong. I don't want to remove these calls, but I want
- >to assure that most programs do not use them. What is good in memory
- >protection when you can easily circumvent it.
-
- How could you assure most programs do not use certain calls?
-
- The question is: how much security do you want?
-
- - Do you want full security (ie. OS *always* running)? This will make it
- hard to run other OS's on the Amiga. It will also stop demo's and games from
- taking over the machine completely.
-
- If this route is taken there should be libraries for manipulating hardware
- such as the copper more directly.
-
- - Or do you want programs that can crash if they take trouble to do it? I
- would be happy with this, after all I could always kill those programs if
- they bothered me too much. I am far more concerned with the accidental
- crashes we have now.
-
- The only way you can get 'them' (you know, the K0derz) to use the OS is to
- built the basic a1200 in 4-5 flavors, each with different hardware. *And*
- change that hardware at regular intervals.
-
- >>An 68000 emulator could run without memory protection, and new programs
- >>should use the MEMF_PUBLIC flag which indicates memory is to be shared
- >>between applications. I don't see any problem here.
- >
- >Why would you want to run 68000 programs unprotected and why do you
- >want to keep separated APIs for 68000 and PowerPC ?
-
- I don't actually *want* to run 680x0 programs unprotected, but adding
- protection to the 680x0 part of the future amiga's seems far more trouble
- than it's worth. The way I see it those machines will either get new
- software (which is protected, and which will replace old software in a short
- period of time) or it will *not* get new software (and die, thereby solving
- the problem the 'other' way).
-
- Adding protection to PPC programs is a lot easier done, because none exist
- yet that can break programming conventions.
-
- As for the separate API's, there will have to be a layer of stubs anyway for
- 680x0 code inside the emulation, it could just as easily compensate for any
- differences between the old and new API's.
-
- Reading back I see I also implied that PPC programs would be unprotected
- from 680x0 programs. What I really meant was 'PPC programs should always be
- protected, 680x0 programs should be allowed to crash each other just like in
- the good old days'.
-
- >And no, MEMF_PUBLIC is probably not a good method and definitely not
- >the best.
-
- It was really a placeholder for 'some way I cannot be bothered to specify or
- even think about to tell the system this memory will be referenced by
- multiple tasks, and is therefore not subject to the full extend of memory
- protection techniques as currently employed by the operating system'. It
- wasn't really meant as a solution although I suppose it could be one.
-
- A better solution would probably take into account that a message has only
- one owner at a time (either the sender is working with it or the receiver -
- never both).
-
-
- Bye,
-
- Hans
-
-